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REMARKS 

Favorable reconsideration of this application is respectfully requested in view of the 
amendments above and the following remarks. By virtue of the amendment, claims 1-16 are 
pending in the present application of which claims 1, 5, 8, 1 1, and 14 are independent and 
claims 14-16 are new. 

Claims 1, 2, 5, 8, and 9 were rejected under 35 U.S.C. § 102(e) as being anticipated 
by Bracha et al. (6,601,1 14). Claims 3, 4, 6, 7 and 10-13 were rejected under 35 U.S.C. § 
103(a) as being unpatentable over Bracha et al. in view of Levy et al. (6,092,147). The above 
rejections are respectfully traversed for at least the reasons set forth below. 

Drawings 

The Office Action Summary did not indicate whether the drawings filed on June 1 , 
2001 are accepted. The Applicants request that the Examiner indicate in the next office 
action whether the drawings are accepted. 

Information Disclosure Statement 

At the outset, the indication that the references cited in the IDS filed on June 1, 2001, 
have been considered is noted with appreciation. 

Claim Rejection Under 35 U,S,C. S102 

The test for determining if a reference anticipates a claim, for purposes of a rejection 
under 35 U.S.C. § 102, is whether the reference discloses all the elements of the claimed 
combination, or the mechanical equivalents thereof functioning in substantially the same way 
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to produce substantially the same results. As noted by the Court of Appeals for the Federal 

Circuit in Lindemann Maschinenfabrick GmbH v. American Hoist and Derrick Co., 221 

USPQ 481, 485 (Fed. Cir. 1984), in evaluating the sufficiency of an anticipation rejection 

under 35 U.S.C. § 102, the Court stated: 

Anticipation requires the presence in a single prior art reference 
disclosure of each and every element of the claimed invention, 
arranged as in the claim. 

Therefore, if the cited reference does not disclose each and every element of the 
claimed invention, then the cited reference fails to anticipate the claimed invention and, thus, 
the claimed invention is distinguishable over the cited reference. 

Claims 1, 2, 5, 8, and 9 were rejected under 35 U.S.C. § 102(e) as being anticipated 
by Bracha et al. 

Claim 1 recites, 

a code verifier configured to analyze instructions of said program and 
to generate a plurality of type signatures based on said instructions, each of 
said type signatures indicating each input type constraint and each output type 
description for a respective one of said instructions, wherein said code verifier 
is configured to detect a type error by analyzing said type signatures. 

Bracha et al. fails to teach or suggest (1) generating a plurality of signatures based on 
said instructions, (2) each type signature indicating each input type constraint, and (3) each 
type signature indicating each output type description for a respective one of said 
instructions. 

Brach et al. discloses lazy linking with module-by-module verification. Brach et al. 
discloses in the description of related art that linking is the process of taking a class at run 
time and combining it with a virtual machine (VM) so the module can be executed. Lazy 
linking loads a class, e.g., an instance of a module, only at the time the class is first necessary 
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to execute an instruction of the class. Verification is performed every time the class is linked. 
Verification ensures that illegal operations are not attempted by a VM that can lead to 
meaningless results. See column 4, lines 28-53. However, in certain instances, when a class 
is referenced by another class, the class may be verified even if it is not used. Also, 
verification is performed at run time, so a class that has been previously verified is verified 
again each time the class is loaded. See column 5,lines 17-28. Thus, Brach et al. discloses a 
pre-runtime, class-by-class, verification process. In Bracha's pre-run time, verification 
process of a class, any intermodule information referencing other modules, such as subtyping 
relationships between classes, is assumed so that instructions in the class being verified are 
valid. However, the assumed information places a constraint on the referenced module that 
must be remembered by the VM. The pre-verification constraints are v^itten to a file for 
checking later at run time. See column 16, line 45-colximn 17, line 28. 

As cited in the rejection and further disclosed by Bracha et al., as a further option, the 
pre-verification constraints, e.g., stored in a file, or the module itself can have an attached 
digital signature to reliably identify the source of the module or constraints. See colxmm 17, 
lines 30-35. The digital signature of Bracha et al. is used to identify the source of the file 
containing the constraints or the module itself. For example, if the digital signature does not 
match the digital signature of a trusted source or entity, then the constraints or module may 
be considered unsafe to use. Thus, the digital signatures of Brach et al. are not generated 
based on the instructions. Instead, a digital signature of Bracha et al. is generated based on 
the identity of a source providing a module or file containing pre-verification constraints. 
Furthermore, the digital signatures of Bracha et al. do not indicate each input type constraint 
and each output type description for a respective one of each instruction. Instead, the digital 
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signatures only identify sources rather than input type constraints or output type descriptions 
of instructions. Accordingly, Bracha et al. fails to teach all the features of claim 1, and 
claims 1-4 are believed to be allowable. 
As stated above, the digital signatures of Bracha et al. 
Independent claim 5 recites, 

a code verifier configured to analyze a code block of said program and to 
translate instructions within said code block into a plurality of type signatures, 
said code verifier further configured to compose said type signatures into a 
single composed type signature and to detect a type error by analyzing said 
type signatures. 

Brach et al. fails to teach a code verifier configured to translate instructions within a 
code block into a plurality of signatures. As stated above, the digital signature disclosed in 
Bracha et al. identifies the source providing the module or file containing pre-verification 
constraints. Brach et al. fails to teach translating instructions into type signatures. Brach et 
al. also fails to teach composing a plurality of type signatures into a single type signature. In 
fact, the rejection of claim 1 1 states that Bracha does not explicitly disclose composing said 
type signatures into a single composed signature. The rejection of claim 11, then combines 
Levy et al. with Bracha et al. to allegedly teach this feature. Thus, the Examiner agrees that 
Bracha et al. fails to teach composing a plurality of type signatures into a single type 
signature. Accordingly, claims 5-7 are believed to be allowable. 

Claim 8 recites features similar to claim 1 , including, 

generating a plurality of type signatures based on instructions within 
said program, each of said type signatures indicating each input type constraint 
and each output type description for a respective one of said instructions. 
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The digital signature of Bracha et al. is used to identify the source of the file 
containing the constraints or the module itself. The digital signatures of Brach et al. are not 
generated based on the instructions. Instead, a digital signature of Bracha et al. is generated 
based on the identity of a source providing the module or file containing the pre-verification 
constraints. Furthermore, the digital signatures of Bracha et al. do not indicate each input 
type constraint and each output type description for a respective one of each instruction. 
Instead, the digital signatures only identify sources rather than input type constraints or 
output type descriptions of instructions. Accordingly, Bracha et al. fails to teach all the 
features of independent claim 8, and claims 8-10 are believed to be allowable. 



Claim Relection Under 35 U.S.C. S103 

The test for determining if a claim is rendered obvious by one or more references for 

purposes of a rejection under 35 U.S.C. § 103 is set forth in MPEP § 706.02(j): 

To establish a prima facie case of obviousness, three basic criteria 
must be met. First, there must be some suggestion or motivation, 
either in the references themselves or in the knowledge generally 
available to one of ordinary skill in the art, to modify the reference 
or to combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art reference 
(or references when combined) must teach or suggest all the claim 
limitations. The teaching or suggestion to make the claimed 
combination and the reasonable expectation of success must both 
be found in the prior art and not based on applicant's disclosure. In 
re VaecK 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). 

Therefore, if the above-identified criteria are not met, then the cited reference(s) fails 

to render obvious the claimed invention and, thus, the claimed invention is distinguishable 

over the cited reference(s). 
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Claims 3, 4, 6, 7 and 10-13 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Bracha et al. in view of Levy et al. 

Independent claim 1 1 recites, translating said instructions into a plurality of type 
signatures and composing said type signatures into a single composed type signature. These 
steps are not taught or suggested by either of Bracha et al. and Levy et al. As stated above, 
the digital signature of Bracha et al. is used to identify the source of the file containing the 
constraints or the module itself. The digital signatures of Brach et al. are not generated based 
on the instructions, and instructions are not translated to generate a plurality of signatures. 
Furthermore, neither Brach et al. nor Levy et al. teach or suggest composing a plurality of 
signatures into a single composed signature. Levy et al. was combined with Bracha et al. to 
allegedly teach this feature. However, Levy et al. also fails to teach or suggest this feature. 
The rejection cites column 7, lines 25-34 to tech this feature. In this passage. Levy et al. 
discloses generating a proof of authenticity for bytecode using any type of cryptographic 
computation, such as hashing. However, Levy fails to teach or suggest composing a plurality 
of type signatures into a single composed type signature, wherein the plurality of type 
signatures are translated from instructions. Thus, claims 11-13 are believed to be allowable. 

Dependent claims 3, 4, 6, 7 and 10 are believed to be allowable for at least the reasons 
stated above that their respective independent claims are believed to be allowable. 
Furthermore, Bracha et al. in view of Levy et al. fails to teach or suggest many of the features 
of these claims, such as translating code blocks into type signatures, composing code type 
signatures for each code block into a single type signature, making a determination as to 
whether an input type constraint of a first type signature is acceptable to an output type 
description of a second type signature, and a type signature including a description indicative 
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of a type of an input consumed by an instruction when the instruction is executed and another 
of type signature including a description indicative of a type of an output produced by 
another instruction when the other instruction is executed. 

Newly Added Claims 

Claims 14-16 are new. Claims 14-16 include features similar to claims 8- 
10 not taught or suggested by Bracha et al. or Levy et al. Accordingly, claims 14- 
16 are also believed to be allowable. 
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Conclusion 

In light of the foregoing, withdrawal of the rejections of record and allowance of this 
application are earnestly solicited. 

Should the Examiner believe that a telephone conference with the undersigned would 
assist in resolving any issues pertaining to the allowability of the above-identified 
application, please contact the undersigned at the telephone number listed below. Please 
grant any required extensions of time and charge any fees due in connection with this request 
to deposit account no. 08-2025. 



Respectfully submitted, 



Christopher J. Dollin 



Dated: September 22, 2004 



By 




Ashok K. Mannava 
Registration No.: 45,301 



MANNAVA & KANG, P.C 
8221 Old Courthouse Road 
Suite 104 



Vienna, VA 22182 

(703) 652-3822 

(703) 880-5270 (facsimile) 
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